Is it worth saying that this is left in for backwards compatibility, and should be removed one day?

I wish I hadn't to paste this here, but this needs to work differently than the WP_Theme_JSON_Gutenberg::scope_selector (do not add an extra space).

Ideas for a follow-up PR:

• The usage of this internal utility has expanded to: settings, duotone, WP_Theme_JSON class. It's worth creating a utility function somewhere. Where? wp_scope_css_selector( $scope, $selector ) as a name?

• The consumer should be responsible for adding or not adding spaces, not the function itself:

  • wp_scope_css_selector( $scope . ' ', $selector ) if the consumer wants spaces.
  • wp_scope_css_selector( $scope . ' ', $selector ) if the consumer doesn't want spaces.

Thoughts?

I think it probably makes more sense to keep this function but just modify it.

This looks like a useful technique for migrating more settings over.

The only problem is that there's no longer any way of knowing if you have experimental support or not. It's causing me problems because the selector that we choose is different depending on whether or not it's experimental.

// May be true even if `filter.duotone` isn't set.
const duotoneSupport = getBlockSupport(
	blockType,
	'filter.duotone',
	false
);

// May be set even if `filter.duotone` is also set.
const experimentalDuotone = getBlockSupport(
	blockType,
	'color.__experimentalDuotone',
	false
);

// Will always produce a selector even if `filter` or `filter.duotone` isn't set.
const duotoneSelector = getBlockCSSSelector(
	blockType,
	'filter.duotone',
	{ fallback: true }
);

EDIT: We could have color.__experimentalDuotone override filter.duotone, but that seems wrong to me. If they're both set, I would expect filter.duotone to override color.__experimentalDuotone.

I'm not sure I follow.

In the filter, we were only setting filter.duotone if it hasn't already been set and the color.experimentalDuotone has been.

A block author shouldn't be using both properties in their raw block.json so if we have color.experimentalDuotone set at all, then it should be a case from when duotone was experimental.

• In your first example, the check for filter.duotone tells us if there is support.
• The second example if the default is removed or changed to null would tell us if the duotone support was the experimental version.
• The third snippet with fallback true would always produce a selector regardless of any support check. We would guard such a call with a check that the color.experimentalDuotone support flag wasn't set.

My thinking was that by leaving the __experimentalDuotone property we could determine when to use that as the selector. I can see from this discussion where I missed adding the guard check to the duotone.js HoC.

I had to do this to fix the experimental selectors in the editor being applied to the root of the block instead of the selector set in __experimentalSelector.

I'm not sure we're on the same page here. The supports.filter.duotone property will only get set if it hasn't been set already and we have supports.color.__experimentalDuotone set.

So supports.filter.duotone will tell us if we have duotone support one way or another. Checking if we have the supports.color.__experimentalDuotone flag set should tell us if we need to handle an experimental duotone selector or use the selectors API requesting selectors.filter.duotone